Network attacks and cyber security is of major importance to security-minded enterprises. Businesses and regulated environments of all markets are requiring authoritative auditing and logging measures of all computing machines connected to their networks. Traditional security solutions may provide enterprises with preventative endpoint protection, where the software reacts to new files entering computing devices, and if deemed malicious automatically stops them from running on the devices. However, attackers are still able to penetrate the computing devices without triggering these defenses.
Current operating systems may include built-in tools for collections and monitoring of processes executed on the computing devices. For example, Apple™ ships the latest version of OpenBSM pre-installed on all macOS™ running computers. OpenBSM is an open source implementation of Sun Microsystems' Basic Security Module (BSM) audit API and file format. OpenBSM collects login and authentication events only in a default configuration, and the events are not stored in a human-readable format.
However, existing security software tools ignore systems such as OpenBSM already built into the operating system and create their own collections and monitoring methods, and in many instances, introduce security issues into the operating system. Thus, enterprises using existing security software may be unwittingly compromising their computing machines. Furthermore, log collection tools cannot ingest logs generated by OpenBSM without some application or script transforming the OpenBSM logs on a set interval. The native OpenBSM log format is not designed for real-time auditing and collection.
Still further, collecting all events that OpenBSM generates will significantly slow down existing computer systems to a point where it is unusable. For example, by observing the stream of all events, additional events will be generated detailing the observation and an infinite loop will be created. Event generation scales with the speed of computer, so this issue will not necessarily be cured over time.
Other existing tools include proof of concept code that can only be run on developer machines under special conditions. These tools are not complete, do not scale, and are not designed to be managed remotely. Furthermore, such tools do not use OpenBSM. OpenBSM may be important, in some aspects, because it uses the Unix™ standard. OpenBSM may be the only way for non-kernel programs to collect security and auditing information. Other collection methods require a vendor to install kernel-level code which introduces instability and new security concerns. In some cases, only specific Kernel extensions may run in the first operating systems and Kernel extensions related to other operating systems may be disallowed by the first operating system.
Other tools ignore systems native to macOS in favor of their own code for monitoring, collection, and blocking of security events. Non-native toolsets require integration testing for each and every sub build of macOS. This vendor code leads to instability and performance issues of the entire system as the vendor's code must approve all actions taken by the system before an action is executed. These conventional systems require vendor kernel extension (kexts). Kexts introduce the possibility of severe security vulnerabilities. Kexts run at the lowest level of the operating system, and any bug or error will crash the system completely. On macOS 10.13.3+, kexts need to be white-listed or approved by the user.
Often macOS system updates need to be delayed at a company so that vendors can update their tools. Updating macOS without updating the vendor's tool will often lead to unusable systems requiring expert assistance from IT. Exact versions required for exact versions of macOS is nearly unsustainable. These tools upload data (including entire files) to vendor cloud for processing and threat analysis. Some tools send data directly to a vendor-hosted cloud server that performs log analysis. No human-readable logs are left on the device or in the cloud. Even if done correctly, many organizations do not want company data on any non-company systems. Windows OS is the dominant operating system in most companies, and most tools are developed for windows first, and then macOS second.
Kernel extensions may be the code that runs at the very highest permission on macOS (e.g., the first operating systems) and may be a required link in the execution chain for relevant operations. Any error in that code may cause catastrophic errors. A kernel extension that works with application executions may be a required step for every single app execution whether or not that kernel module is doing anything with that specific application.
Other challenges for existing solutions include a low level of documentation for macOS and limited (or sometimes incorrect for macOS) documentation from Oracle's Sun operating system. Security application vendors may have been focused more on blocking potential threats rather than just reporting on them.
There are extremely few security applications developed solely for macOS. Typically, macOS is a secondary platform and not the primary development focus, resulting in crashing systems.
The present disclosure is directed to addressing one or more of these above-referenced challenges. The background description provided herein is for the purpose of generally presenting the context of the disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art, or suggestions of the prior art, by inclusion in this section.